inputmode helps to choose the appropiate virtual keyboard, when i.e. type='text' is to use, but also special characters like spaces or hyphens are allowed. This is very helpful on mobile devices.

A common use case are formatted numeric inputs like credit card numbers, IBAN, article numbers or similair.

It is an addition to the type attribute and does no harm. The default is null, so it should not be set.

For that use case I think we should use something like <TextField type="number" /> to be consistent with what we're already doing. It's not implemented yet but it should be enough to allow the number string in the type prop validator.

https://github.com/nextcloud/nextcloud-vue/blob/master/src/components/NcTextField/NcTextField.vue#L169

It's not implemented yet but it should be enough to allow the number string in the type prop validator.

Not sure, if I get you right. Since '2345-3765-7654-7695' is not a number, the type 'number' is wrong, following the specification of https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/number.

<input> elements of type number are used to let the user enter a number. They include built-in validation to reject non-numerical entries.

Little bit more explanation:

If the expected format of an input field is like in the example above, the type has to be text. number is not usable in this case and the input will be rejected. But when the type is text the user will be presented a virtual keyboard with characters (the default I guess). But only numbers are expected for input. But extended with inputmode="numeric" the numeric keyboard is offered.

That is, why inputmode was introduced, responsiveness in mind.

Supportd by nearly all mobile browsers: https://caniuse.com/input-inputmode

Sorry for the late reply @dartcafe. Is that the only use-case that is not contemplated by the type attribute? If that is the case I would just accept numeric. For email and url we can just use type, right?
My concern here is not making these components too complicated and limit the usage patterns. For example I would like to avoid having:
<NcTextField inputmode="email" />
in favor of:
<NcTextField type="email" />

Is that the only use-case that is not contemplated by the type attribute?

That is one use case, which helped me to get a better UX with article numbers and masked fields, where type=number was not possible.

Some other use cases you can find in this article and this. Maybe that helps to get an overview.

The point is, that inputmode can define a virtual keyboart explicitly, while type defines it implicitly. I guess there is a reason, why all mobile browsers support this living standard.

closing in favour of #3485